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^-Munich 
SO 

Beschreibung 

Bearbeitung einer IP-Adresse auf Systemebene 

Die Erfindung liegt auf dem Gebiet der Datenkommunikation ii- 
ber das Internet und betrifft insbesondere ein Verfahren und 
eine Systemkomponente, mittels dessen/der mindestens eine 
Routine zur Verarbeitung von IP-Adressen, die bei einer Er- 
stellung von einer Vielzahl von internet-spezif ischen Appli- 
kationsprogrammen notwendig ist, bereitgestellt wird. 

Da die Kommunikation tiber das Internet zunehmend an Bedeutung 
gewinnt, steigt ebenso die Bedeutung fur die Entwicklung von 
internetspezif ischen Programmen. 

Sollen beispielsweise zwei iiber das Internet erreichbare Ma- 
schinen Daten austauschen, muB erst einmal die Grundlage da- 
fur geschaffen seirf, dafi sie miteinander kommunizieren kon- 
nen. Dazu wird jeder ttber das Internet erreichbaren Maschine 
eine eineindeutige Adresse zugeordnet. Diese besteht gegen- 
wartig (bei dem IPv4 Protokoll) aus je vier Zahlen, deren 
Wert zwischen 0 und 255 liegt. Oblicherweise werden zur 
leichteren Benennung und besseren Erinnerungsf ahigkeit Namen 
eingesetzt, die wiederum diesen numerischen Adressen zugeord- 
net sind. 

Um Netzwerkarchitekturen grundsatzlich moglichst kompatibel 
zu machen, ist von der "International Standards Organization 
(ISO) eine internationale Norm, das sogenannte OSI- 
Ref erenzmodell (Open Systems Interconnection) eingefuhrt wor- 
den. Die zugrundeliegende Idee fur dieses Normenmodell ist 
die Idee die Netzwerkarchitektur in hierarchisch strukturier- 
ten Schichten zu gliedern, die aufeinander aufbauen. Dabei 
kortununiziert eine bestimmte Schicht einer Maschine mit der 
entsprechenden Schicht der anderen Maschine. Die Regeln, auf- 



grund deren diese Koirununikation ablauft sind in einem Proto- 
koll definiert. 

Das bekannte IP (Internet Protocoll) Vermittlungsprotokoll 
basiert auf transparenten Internet-Datagrammen und ist grund 
5 satzlich verbindungsunabhangig. 

Das IP-Protokoll hat grundsatzlich folgenden Ablauf : 
Die Transportschicht nimmt Nachrichten auf und gliedert sie 
in Datagramme, die uber das Internet tibertragen werden. Wenn 
alle Datagramme die Zielmaschine erreicht haben, werden sie 
10 von der dortigen Transportschicht vereinigt, so dafi die Ori- 
ginalnachricht abfcufbar ist. 



Ein sogenannter IP-Header ist jeder Nachricht vorangestellt 
und besteht aus mehreren Eintragen, die unter anderem die 
15 Quelladresse und die Zieladresse umfassen. Die Adressen zei- 
gen die Netzwerk- und die Hostnummer an. 

Eine IP-Adresse ist grundsatzlich eine 32-Bit-Adresse (= 4- 
Byte-Adresse) , die aus einer Netzidentif ikation und einer 

20 Hostadresse besteht. Als Format fur die einzelnen Adressen 

hat sich eine Vier-Punkt-Notation durchgesetzt . Die vier ein- 
zelne Bytes der Adresse sind jeweils durch einen Punkt ge- 
trennt. Festgelegte Bereiche sind fur die Netzwerkidentif ika- 
tion und die Identif ikation der Hostadresse bestimmt. Diese 

25 beiden Bereiche sind in ihrer Grofie variabel. Grundsatzlich 
werden hierfur vier unterschiedliche Darstellungsm6glichkei- 
ten verwendet. Diese erlauben die Codierung einer unter- 
schiedlichen Anzahl von Netzwerken und Hosts. 

30 Um einerseits die Effizienz der Obertragung einer Nachricht 
iiber ein Netz zu steigern, ist es wichtig, das Verhaitnis 
zwischen IP-Header und der eigentlichen Nachricht mdglichst 
klein zu halten. Dazu mufi der fur die Darstellung der IP- 
Adresse erf orderliche Speicherplatz moglichst klein gehalten 

35 werden. Deshalb werden IP-Adressen haufig in komprimierter, 
gepackter Form tibertragen. 
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Andererseits ist es erf orderlich, auch ein unkomprimiertes 
Format, also ein explizites Format bzw. eine explizite Dar- 
stellung zu verarbeiten. 

5 Nahezu bei alien IP-basierten Losungen ist deshalb eine Ver- 
arbeitung und insbesondere eine Konvertierung der unter- 
schiedlichen I P-AdreB formate (beispielsweise die Konvertie- 
rung der expliziten Darstellung in die komprimierte und umge- 
kehrt) erf orderlich, 

10 

VergegenwSrtigt man sich weiterhin, wie hSufig IP-Adressen 
verarbeitet werden, so besteht hier ein immenser Bedarf , die- 
se IP-Adressen-Verarbeitung mit mSglichst maximaler Perfor- 
mance auszuf Ohren. Denn in der Verarbeitung von IP-Adressen 

15 liegt ein die Performance des Gesamtsystems wesentlich mitbe- 
stimmender Faktor: Ist bereits die Verarbeitung - beispiels- 
weise die Konvertierung - einer IP-Adresse verzSgert, dann 
ist auch zwangslaufig die darauf basierende Applikation ver- 
z5gert. Dieser Zustand ist aus Perf ormancegrunden nicht trag- 

20 bar. 

Um IP-Adressen optimiert zu verarbeiten, wird neben dem ex- 
pliziten Format (bei einer Hexadezimal Darstellung 11 Byte, 
bei einer Dezimaldarstellung 15 Byte) zusatzlich ein kompri- 

25 miertes Format (z.B. ein 32-Bit-Wort - 4Byte) verwendet, das 
es ernioglicht, die Daten in gepackter Form zu transf erieren . 
Soli nun eine solche IP-Adresse im Rahmen einer Applikation 
verarbeitet werden, so ist nahezu immer eine Konvertierung 
von einem Format in das andere erf orderlich. Es mufi also eine 

30 Routine zur Umwandlung aus dem expliziten Format in das kom- 
rimierte Format und aus dem komprimierten Format in das ex- 
plizite Format zur Verfugung gestellt werden. 

Bisher wurde in jeder Applikationssof tware einzeln und unab- 
35 hangig voneinander eine Routine mit entsprechender Konvertie- 
rungsf unktionalitat vorgesehen. Da die Routine zur Formatum- 
wandlung von IP-Adressen aber zum einen sehr hSufig benotigt 




ward und zum anderen sehr zeitkritisch ist, ist das bisherige 
Vorgehen, nSmlich die Routine dezentrai vorzusehen, nicht 
sinnvoll . 

5 Auch aus Grunden der Performance erweist sich dieses Vorgehen 
als nachteilig. 

Es ist zwar bekannt, bestimmte Routinen in sogenannte Pro- 
grammbibliotheken vorzusehen, beispielsweise DLL-Files (Dyna- 

10 mic Link Library Files) . In diesem Zusammenhang zeigt die US 
5634114 ein Verfahren, das die korrekte Zuordnung eines DLL- 
Files und eines dieses File aufrufenden Applikationsprogramms 
steuert. Denn in einer solchen Programmbibliothek werden hau- 
fig verschiedene Versionen eines DLL-Files abgelegt. BenQtigt 

15 die Applikation eine ganz bestimmte Version dieses DLL-Files , 
dann wird mit diesem Verfahren die Auswahl des passenden DLL- 
Files uberwacht . 

Die MSglichkeit, eine Routine in eine Programmbibliothek zu 
stellen ist allerdings nur eine der m6glichen MaJinahmen, die 
20 die vorliegende Erfindung vorsieht, urn eine Format- 

Konvertierungs-Routine fttr IP-Adressen an zentraler Stelle im 
System und auf Systemebene (und nicht mehr auf der Ebene des 
Applikationsprogramms) vorzusehen. 

25 Als nachteilig erweist es sich ferner, dafc bisher fur jede 
einzelne IP-Applikation jeweils eine eigene IP-Adressen- 
Verarbeitungsroutine geschrieben, ubersetzt und getestet wer- 
den muJl. Dies erhoht die Fehlerwahrscheinlichkeit und fiihrt 
zu einer redundanten Entwicklungsarbeit . 

30 

Die vorliegende Erfindung hat sich deshalb zur Aufgabe ge- 
stellt ein Verfahren und entsprechende Systemkomponenten zur 
Verfugung zu stellen, die eine moglichst schnelle Verarbei- 
tung von IP-Adressen, insbesondere von deren Formaten, erm6g- 
35 lichen ohne daB ftir jedes Applikationsprogramm eine eigene 

Routine generiert und ubersetzt werden muB, so da& die Routi- 
ne als Standard fur mehrere IP-Applikationen dienen kann. 



i 



1 5-02-2001 




Die Losung der Aufgabe gem&ft Anspruch 1 besteht insbesondere 
darin, dafi eine Routine zur Verarbeitung von IP-Adressen, 
insbesondere eine Konvertierungsroutine fttr verschieden For- 
5 mate von IP-Adressen, an zentraler Stelle innerhalb eines 
Computer systems vorgesehen ist und nicht fur jede einzelne 
IP-Applikation einzeln und erneut programmiert und iibersetzt 
zu werden braucht. 

10 Das Integrieren der Routine auf Systemebene bzw. in eine Sys- 
temkomponente kann dadurch erfolgen, indem die Routine in ein 
Betriebssystem integriert wird. 

Alternativ kann die Routine auch in einem Compiler integriert 
15 sein, der entweder einen entsprechenden Aufruf einer Routine 
im Betriebssystem veranlafit, falls letzteres dies unter- - 
stilt zt. Andernfalls enthalt der Compiler spezifischen Prozes- 
sor-Code, der die Verarbeitung von IP-Adrefif ormaten, insbe- 
sondere deren Konvertierung, ausfuhrt. Ebenso liegt ein fur 
20 die Verarbeitung, insbesondere Konvertierung, von IP-Adressen 
ausgelegter Assembler oder Interpreter im Rahmen der Erfin- 
dung. 

Es ist jedoch auch mSglich, die Routine zur Verarbeitung von 
25 IP-Adressen in Hardware umzusetzen. Dazu wird zumindest ein 
Register vorgesehen, dessen Inhalt entsprechenden Rechenope- 
rationen unterzogen wird, die das gewiinschte Ergebnis lie- 
fern. Vorzugsweise werden solche Bauteile verwendet, die es 
ermoglichen, dafi zwischen dem Input und dem Output nur ein 
30 Takt liegt. Dies fiihrt zu einer signifikant gesteigerten Per- 
formance. 

Es bestehen verschiedene Versionen des Internet Protokolls 
(beispielsweise das heute gangige IPv4 und dessen Nachfolge- 
35 entwicklung das IPv6) . Eine hauptsachliche Anderung von der 
Version 4 zur Version 6- besteht in der Vergrofierung des IP- 
Adreliraumes. Durch die Erweiterung der Adrefilange von bisher 
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32 Bit auf 128 Bit entsteht eine enorm hohe Zahl von mogli- 
chen Adressen. Damit steigt naturlich auch die erf orderliche 
Rechenleistung fur die Verarbeitung dieser Adressen. Von da- 
her entsteht die Notwendigkeit, eine effiziente Verarbeitung 
5 der komplexeren IPv6 Adressen zur Verfiigung zu stellen. 

In einer bevorzugten Ausf uhrungsf orm der Erfindung wird des- 
halb das Verfahren auf das IPv6 angewendet. 

Mit dem erf indungsgemafien Verfahren entsteht der Vorteil, dafi 
10 nicht jede einzelne Anwenderroutine zur Verarbeitung der IP- 
Adressen einzeln getestet werden mufi, sondern, dafi die Routi- 
ne einmal an zentraler Stelle zur Verfiigung gestellt ist. Da- 
mit sinkt der Testaufwand und es steigt die Performance. 

15 Da jede Generierung von Programmcode auch mit einer gewissen 
Fehlerwahrscheinlichkeit einher geht, wirkt es sich auf die 
Fehlerbilanz als vorteilhaft aus, dafi der IP- 
Verarbeitungscode lediglich einmal als Standard erstellt zu 
werden braucht. 

20 

Die Aufgabe der Erfindung wird neben dem erf indungsgemafien 
Verfahren ferner mit einer erf indungsgem&fi und spezifisch an- 
gepafiten bzw. erweiterten Systemkomponente gelost, die die 
Umwandlung von IP-Adrefif ormaten an zentraler Stelle innerhalb 
25 des Systems vorsieht. 

Die Systemkomponente kann ein erweitertes Betriebssystem, ein 
erweiterter Compiler (bzw. Assembler oder Interpreter) oder 
eine spezifische Hardware Realisierung sein. 

Eine Ausf uhrungsf orm der Erfindung bezieht sich deshalb auf 
30 einen Compiler mit einer Bibliothek, in der eine Routine zur 
Verarbeitung von IP-Adressen enthalten ist. 

In einer vorteilhaf ten weiteren Ausf uhrungsf orm der Erfindung 
wird die Systemkomponente aus einem spezifischen Protokoll- 
35 prozessor, beispielsweise einem ASIC (Application Specific 
Integrated Circuit) gebildet. Diese Hardware Bausteine sind 
entweder speziell ftir die eine Anwendung, in diesem Fall die 
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Format konvertierung von IP-Adressen ausgelegt oder die For- 
mat kon vert ierung wird in einen ASIC aus einem anderen Umfeld 
integriert . 

5 Vorteilhaf terweise ist die erf indungsgemafie Verlagerung der 
Routinenf unktionalitat von Applikationsebene auf Systemebene 
prozessorunabhangig und kann fiir verschiedene Umgebungen ein- 
gesetzt werden. 

10 Gegenstand der Erfindung ist allerdings nicht nur die vorste- 
hend beschriebene Funktionalitat der Routine zur Konvertie- 
rung von IP-Adressf ormaten, sondern ist weiterhin in einer 
Routine zu sehen, die eine andere Funktionalitat bei der Ver- 
arbeitung von IP-Adressen aufweist. So ist beispielsweise 

15 auch die In- oder Dekrementation von IP-Adressen umfafit. 

Andere vorteilhafte Weiterbildungen der Erfindung ergeben 
sich aus den Unteranspriichen. 

20 Weitere Vorteile der Erfindung und besondere Ausftihrungsf or- 
men mit deren Merkmalen sind in der nachf olgenden detaillier- 
ten Figurenbeschreibung dargestellt. Darin zeigt: 

Fig. la eine schematische Darstellung eines Formates einer 
25 IP-Adresse in komprimierter Darstellung, 

Fig. lb eine schematische Darstellung des Formates des IP- 
Adresse in expliziter Darstellung und 

30 Fig. 2 ein Flulidiagramm fur eine Durchfiihrung des Verfah- 
rens gemali einer bevorzugten Aus ftthrungs form der Erfindung. 
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Nachfolgend wird unter Bezugnahme auf Figur 1 ein Beispiel 
far eine Darstellung einer im allgemeinen mit 10 bezeichneten 
IP-Adresse gezeigt . 



Figur la zeigt eine ubliche 32-bit-Darstellung bzw. eine 
Vier-Byte-Darstellung. Diese Darstellung wird nachfolgend als 
komprimiertes Format 14 bzw. komprimierte Darstellung 14 be- 
zeichnet. Die in Figur la bzw. lb dargestellte schematische 
Darstellung bezieht sich jeweils auf Little Endian Rechner, 
deren Numerierung der Speicherblocke von rechts beginnend 
nach links erfolgt. 

Die einzelnen Blocke konnen Zahlenwerte von 0 bis 255 anneh- 
men, also insgesamt 256 Zeichen. 

Eine IP-Adresse 10 darf weltweit nur einmal vergeben werden, 
urn eine eineindeutige Zuordnung zwischen der IP-Adresse 10 
und dem entsprechenden Rechner zu ermdglichen . 

Sollen IP-Adressen 10 nun verarbeitet werden, so ist es aus 
Perf ormancegr linden sinnvoll, eine komprimierte bzw. gepackte 
Darstellung 14 zu wahlen. Neben diesem Format wird aber auch 
noch ein explizites Format 12 verwendet, das schematisch in 
Figur lb dargestellt ist und grofier ist als das komprimierte 
Format 14 der IP-Adresse 10. Aus Perf ormancegrunden wird das 
komprimierte Format 14 vorteilhaf terweise zum Datentransf er 
eingesetzt. Doch ebenso kann aus Standardisierungsgrunden ein 
Transfer des expliziten Formats 12 notwendig sein, das an- 
sonsten ublicherweise fur die Ausgabe auf dem Terminal ver- 
wendet wird. Unabhangig von der jeweiligen Anwendung ist bei 
alien IP-basierten Anwendungen eine Umwandlung der verschie- 
denen Formate 12, 14 der IP-Adresse 10 notwendig. 

Fig. lb zeigt schematisch ein Beispiel far ein explizites 
Format 12 , das hier hexadezimal dargestellt ist und 11 Bytes 
umf alit . 

Um einen effiziente Datentransf er von IP-Adressen 10 zu er- 
moglichen, ist eine Umwandlung von dem expliziten Format 12 
in das komprimierte Format 14 und umgekehrt notwendig. 

Eine entsprechende Routine 16, die eine solche Umwandlungs- 
funktionalitat zur Verfugung stellt, mulite bisher fur jedes 




einzelne Applikationsprogramm, das IP-Adressen VO verarbeitet 
stets neu codiert, compiliert und mit anderen Objekt-Files 
zusammen zu einem ausftihrbaren Applikationsprogrammcode ge- 
linkt werden. 

5 

Dieses Vorgehen erweist sich aus verschiedenen Griinden als 
nachteilig, da die wiederholte Ausfuhrung eines identischen 
Vorganges das Auftreten von Fehlern erhoht. Deshalb ist eine 
Standardisierung der Umwandlungsfunktionalitat sinnvoll. 

10 

Wie in Figur 2 dargestellt, wird erf indungsgemaB die Routine 
16, insbesondere die Umwandlungsroutine 16, an zentraler 
Stelle des Computersystems angeordnet und somit von der Ap- 
plikationsebene auf die Systemebene verlagert. Dies wird er- 

15 moglicht, indem die Routine 16 in eine Systemkomponente 18,' 
20, 22 integriert wird, die def initionsgem^B fester Bestand- 
teil des Systems ist. Die Erweiterung der Systemkomponente 
18, 20, 22 findet zeitlich vor der Generierung des Applikati- 
onscodes statt und ist deshalb in der Zeichnung mit einer ge- 

20 strichelten Linie von den zeitlich nachf olgenden Bereichen 
abgesetzt. Die Systemkomponente kann : 

1. ein Compiler 18 (bzw. ein Assembler) sein, der diese Funk- 
tionalitat der Umwandlung von IP-Adrefif ormaten umfalit, 

2. ein Betriebssystem 20, das die Funktionalitat der Umwand- 
25 lung von IP-AdreBf ormaten umfalit und 

3. ein Mikroprozessor 22, der Funktionalitat der Umwandlung 
von IP-Adrefiformaten bereits auf Hardwareebene bereit stellt. 

Selbstverstandlich liegen noch weitere Ausf iihrungsf ormen im 
30 Rahmen dieser Erfindung, die ebenfalls die Integration einer 
Routine 16 zur Umwandlung von IP-Adrefif ormaten in einer zent- 
ralen Systemkomponente ermSglichen. 

Soli die Routine 16 in den Compiler 18 integriert werden, 
35 dann kann dies durch den Aufruf einer entsprechenden Be- 

triebssystemroutine erfolgen, falls das Betriebssystem diese 
Konvertierungsf unktionalitat unterstutzt. Andernfalls wird 
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ein entsprechender Prozessor-Code generiert. Naturlich liegt 
auch eine Verwendung von einer Bibliothek im Rahmen der Er- 
findung, auf die iiber einen Compilerauf ruf zugegriffen wird 
und die eine zusatzliche Konvertierungsf unktion von IP- 
5 Adressen 10 ausfiihrt, wie z.B. ein spezielles DLL-File 
"ip_convert" (Dynamic Link Library File) . 

Vorteilhaft erweist es sich dabei, daB die Routine 16 erfin- 
dungsgemaB nur einmal, n&mlich im Rahmen des Integrationsvor- 
10 ganges kompiliert und gelinkt zu werden braucht. Dies fuhrt 
zu einer deutlich verbesserten Performance, zu einer positi- 
veren Arbeitsspeicher Bilanz und senkt die Fehlerwahrschein- 
lichkeit . 

15 Die Aufgabe der Erfindung wird neben dem erf indungsgemSBen 

Verfahren ferner mit einer spezifisch angepaBten Systemkompo- 
nente 18, 20, 22 gelost, die die Umwandlung von IP- 
Adrefiformaten 12, 14 an zentraler Stelle innerhalb des Sys- 
tems vorsieht. 

20 

Insbesondere kann das Betriebssystem 20 mit einer zentralen 
Konvertierungsroutine 16 von IP-Adressen 10 erweitert sein* 

Bei zeitkritischen Anwendungen ist die Performance besonders 
25 wichtig. Hier erweist es sich als sehr sinnvoll, die Routine 
16 nicht in Software vorzusehen sondern ebenso an zentraler 
Stelle im System, jedoch bereits auf Hardware Ebene bereit zu 
stellen. Dazu wird ein Mikroprozessor 22 mit Speicherelemen- 
ten (RAM, ROM, EE PROM) , insbesondere mindestens einem Regis- 
30 ter, mindestens einem Rechenwerk, einer I/O-Einheit und einem 
Daten- und AdreBbus verwendet, der zusatzlich eine Verarbei- 
tungseinheit , insbesondere eine Konvertierungseinheit fur IP- 
AdreBf ormate, aufweist. Die Verarbeitungseinheit umfaBt vor- 
zugsweise ein Register, dessen Inhalt mit einer mSglichst mi- 
35 nimalen Taktzahl verarbeitet werden kann. 
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Patentanspruche 

1. Verfahren zur Bereitstellung von zumindest einer Routine 
(16) zur Verarbeitung einer IP-Adresse (10) , insbesondere zur 

5 Konvertierung von unterschiedlichen Formaten (12, 14) der IP- 
Adresse (10) , wobei die Routine (16) zur Erstellung von einer 
Vielzahl von internetspezif ischen Applikationsprograitimen not- 
wendig ist, indem 

die Routine (16) in zumindest eine Systemkomponente (18, 
10 20, 22) integriert wird, und 

durch einen Link oder einen Zugriff in dem Applikations- 
programm bereit gestellt wird, 

2. Verfahren nach Anspruch 1, 
15 dadurch gekennzeichnet , dali 

die Routine (16) eine Konvertierungsroutine ftir die Formate 
(12, 14) der IP-Adresse (10) ist. 

3. Verfahren nach mindestens einem der vorstehenden Anspru- 
20 che, 

dadurch gekennzeichnet, daJi 

die Routine verschiedene Formate (12, 14) der IP-Adresse (10) 
ineinander umwandelt, insbesondere ein explizites Format 
(12) , das zur Darstellung der IP-Adresse (10) bestimmt ist, 
25 und ein komprimiertes Format (14), das fur den Datentransf er 
bestimmt ist. 

4. Verfahren nach mindestens einem der vorstehenden Ansprti- 
che, 

30 dadurch gekennzeichnet, dafi 

die Routine (16) auf dem Internet Protokoll IPv4 basiert und 
zugeh6rige Adrefif ormate verarbeitet. 
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5. Verfahren nach mindestens einem der Anspriiche 1 bis 3, 
dadurch gekennzeichnet, daft 

die Routine (16) auf dem Internet Protokoll IPv6 basiert und 
zugehSrige Adreft formate verarbeitet. 

5 

6. Verfahren nach mindestens einem der vorstehenden Ansprii- 
che , 

dadurch gekennzeichnet , daft 

die Routine (16) derart in der Systemkomponente (18, 20, 22) 
10 integriert ist, daft ein Kompilieren der Routine (16) bei Er- 
stellung eines ausfiihrbaren Applikationsprogrammcodes nicht 
notwendig ist. 

7 . Verfahren nach mindestens einem der vorstehenden Ansprii- 
15 che, 

dadurch gekennzeichnet, daft 

die Systemkomponente ein Betriebssystem (20) ist, das als 
Umgebung fur das Applikationsprogramm dient. 

20 8. Verfahren nach mindestens einem der Anspriiche 1 bis 7, 
dadurch gekennzeichnet, daft 

die Systemkomponente ein Compiler (18) oder ein Assembler 
oder ein Interpreter ist, der zur Obersetzung des Applikati- 
onsprogramms verwendet wird. 

25 

9. Verfahren nach mindestens einem der Anspriiche 1 bis 7 f 
dadurch gekennzeichnet, daft 

die Systemkomponente ein Mikroprozessor (22) ist r der die 
Routine (16) und/oder das Applikationsprogramm ausfiihrt. 
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10. Systemkomponente, die zur Ausfuhrung des Verfahrens nach 
zumindest einem der vorstehenden Anspruche 1 bis 9 bestimmt 
ist, 

dadurch gekennzeichnet , dali 
5 die Systemkomponente (18, 20, 22) ein zusatzliches Mittel 

aufweist, das zur Verarbeitung einer IP-Adresse (10) bestimmt 
ist, insbesondere eine Konvertierung von verschiedenen Forma- 
ten (12, 14) der IP-Adresse (10) vorsieht. 

10 11. Compiler, der zur Ausfuhrung des Verfahrens nach mindes- 
tens einem der vorstehenden Anspruche 1 bis 9 bestimmt ist, 
mit einer zusatzlichen Einheit, die zur Verarbeitung einer 
IP-Adresse (10), insbesondere von Formaten (12, 14) der IP- 
Adresse (10) bestimmt ist. 

15 

12. Compiler nach Anspruch 11, 
dadurch gekennzeichnet, dafi 

eine Bibliothek, auf die der Compiler (18) bei der Oberset- 
zung zu greift, ein Modul aufweist, das zur Verarbeitung ei- 
20 ner IP-Adresse (10), insbesondere von Formaten (12, 14) der 
IP-Adresse (10) bestimmt ist. 

13. Mikroprozessor, der zur Ausfuhrung des Verfahrens nach 
mindestens einem der vorstehenden Anspruche 1 bis 9 bestimmt 

25 ist, mit einer Verarbeitungseinheit, die eine Verarbeitung 
einer IP-Adresse (10) , insbesondere eine Konvertierung von 
Formaten (12, 14) der IP-Adresse (10), ausfiihrt, indem der 
Inhalt zumindest eines Registers bestimmten Verarbeitungsope- 
rationen unterzogen wird. 
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Zusammenfassung 
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Bearbeitung einer IP-Adresse auf Systemebene 

5 

Die Erfindung betrifft ein Verfahren und eine Systemkomponen- 
te (18/ 20/ 22)/ das/die eine Routine (16) zur Konvertierung 

10 der Formate (12/ 14) einer IP-Adresse (10) an zentraler Stel- 
le im System bereitstellt . Damit wird die Format konvertierung 
als Standard fur alle IP-basierten Applikationsprogramme ein- 
gefiihrt. Die Systemkomponente wird durch ein speziell ange- 
pailtes Betriebssystem (20)/ einen erweiterten Compiler (18) 

15 Oder durch einen spezifischen Hardware-Mikroprozessor (22) 
gebildet • 



20 Figur 2 



o 



p age Blank fuspfoj 




2/2 



I 

I 



Erweiterung einer Systemkomponente durch: 
Integration der Konvertierungsroutine fur 
I P-Adressen-Formate 



Erstellung einer Applikation unter 
Verwendung der Systemkomponente 
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Zugriff / Aufruf / Link auf erweiterte 
Systemkomponente 



Fig. 2 




